Selectable depacketizer architecture

ABSTRACT

A scheme is provided that permits the use of a selectable depacketization module to depacketize data streams. An RTP session manager is responsible for receiving RTP packets from a network and parsing/processing them. A depacketizer module is located using the type of data received on the stream. Thus a specific depacketizer is located at runtime depending on the coding decoding scheme (“codec”) used to compress the incoming data stream. A naming convention is followed in order for a specific depacketizer to be located. The depacketizer receives data that has already been parsed and is in a readable form. The depacketizer outputs this data using a well defined interface. This interface has been designed such that it is generic across a number of codecs. The interface passes all relevant information to the decoder where the actual depacketized data stream will be decompressed. The session manager need not know of any codec details since the depacketizer handles all codec specific issues. A default format is described for data that is output by a depacketizer. There is provision for a depacketizer to output data in this pre-defined format. However, there is also a provision for a depacketizer to output data itself in a pre-defined format. This data is provided to a handler that is aware of this format, so that the integration of depacketizers is seamless. Thus, a depacketizer can be made available as long as it implements certain defined interfaces.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of sending and receiving datapackets on a computer network.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The owner has no objection tothe facsimile reproduction by anyone of the patent document or thepatent disclosure, as it appears in the Patent and Trademark Officepatent file or records, but otherwise reserves all copyright rightswhatsoever.

2. Background Art

Computers are often used to process, play back, and display video data,audio data and other data. This data may come from sources such asstorage devices, on-line services, VCRs, cable systems, broadcasttelevision tuners, etc. Video and audio data is memory intensive, thatis, such data requires large amounts of memory for storage and use by acomputer system. In addition, the transmission time of such large volumedata from a remote source to a client computer can be expensive and be alimiting factor in the ability to provide such data at all.

To reduce the transmission bandwidth and memory requirements whenworking with data, various compression schemes have been developed sothat less storage space is needed to store information and a smallerbandwidth is needed to transmit it. Prior art video compression schemesinclude Motion JPEG, MPEG-1, MPEG-2, Indeo, Quicktime, True Motion-S,CinePak, and others. Similarly, there are a number of compressionschemes for audio data.

The use of compression schemes for transmitting video and audio isparticularly important in the context of computer networks, such as theInternet and World Wide Web. Providers wish to provide multi-mediacontent that includes video and audio to users and transmit such contentover the Internet. Transmission times become too long if the data is notcompressed. In addition, it is not possible to provide real timestreaming of video and audio data without a compression scheme.

RTP is a Real Time Transport protocol used to transmit audio and videoon a network such as the Internet. Typically, audio or video data iscompressed using a specific compression technique and the compresseddata stream is broken down into smaller packets for transmission overthe wire. This process is referred to as “packetization” and the reverseprocess, i.e. assembling network packets into a continuous byte streamis called “depacketization”. An RTP session handler is a mechanism thatcontrols the receipt and depacketization of packetized data at a clientcomputer. In the prior art, the depacketization scheme is part of theRTP session handler's code. This is a disadvantage because it requiresthat the RTP session handler have foreknowledge of all possiblepacketization schemes. This makes it difficult to add new packetizationschemes without requiring that a new RTP session handler be created. Itwould be advantageous if the depacketization could exist as a separatemodule.

SUMMARY OF THE INVENTION

A scheme is provided that permits the use of a selectabledepacketization module to depacketize data streams. An RTP sessionmanager is responsible for receiving RTP packets from a network andparsing/processing them. A depacketizer module is located using the typeof data received on the stream. Thus a specific depacketizer is locatedat runtime depending on the coding decoding scheme (“codec”) used tocompress the incoming data stream. A naming convention is followed inorder for a specific depacketizer to be located. The depacketizerreceives data that has already been parsed and is in a readable form.The depacketizer assembles this data into frames and outputs frame datato a handler according to an interface of the preferred embodiment. Thisinterface has been designed such that it is generic across a number ofcodecs. The interface passes all relevant information to the decoderwhere the actual depacketized data stream will be decompressed. Thesession manager need not know of any codec details since thedepacketizer handles all codec specific issues.

A default format is described for data that is output by a depacketizer.There is provision for a depacketizer to output data in this pre-definedformat. However, there is also a provision for a depacketizer to outputdata itself in a pre-defined format. This data is provided to a handlerthat is aware of this format, so that the integration of depacketizersis seamless. Thus, a depacketizer can be made available as long as itimplements certain defined interfaces. Special intelligence on packetloss, error recovery, and other data can be utilized by the depacketizerand various proprietary codecs are allowed to be used inside of the RTPsession manager, making use of the protocol state management code of thesession manager.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary computer system forimplementing the present invention.

FIG. 2 ilustrates the RTP Session Manager of the present invention.

FIG. 3 illustrates the RTP Depacketizer of the present invention.

FIG. 4 is a flow diagram of the process of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention is a method and apparatus for providing a selectabledepacketizer. In the following description, numerous specific detailsare set forth to provide a more thorough description of embodiments ofthe invention. It will be apparent, however, to one skilled in the art,that the invention may be practiced without these specific details. Inother instances, well known features have not been described in detailso as not to obscure the invention.

JAVA

The preferred embodiment of the invention is implemented in the Java®language developed by Sun Microsystems, Inc. of Mountain View, Calif.The following is background on Java and on object oriented programming.

Java is an object-oriented programming language. Object-orientedprogramming is a method of creating computer programs by combiningcertain fundamental building blocks, and creating relationships amongand between the building blocks. The building blocks in object-orientedprogramming systems are called “objects.” An object is a programmingunit that groups together a data structure (instance variables) and theoperations (methods) that can use or affect that data. Thus, an objectconsists of data and one or more operations or procedures that can beperformed on that data. The joining of data and operations into aunitary building block is called “encapsulation.

An object can be instructed to perform one of its methods when itreceives a “message.” A message is a command or instruction to theobject to execute a certain method. It consists of a method selection(name) and a plurality of arguments that are sent to an object. Amessage tells the receiving object what operations to perform.

One advantage of object-oriented programming is the way in which methodsare invoked. When a message is sent to an object, it is not necessaryfor the message to instruct the object how to perform a certain method.It is only necessary to request that the object execute the method. Thisgreatly simplifies program development.

Object-oriented programming languages are predominantly based on a“class” scheme. The class-based object-oriented programming scheme isgenerally described in Lieberman, “Using Prototypical Objects toImplement Shared Behavior in Object-Oriented Systems,” OOPSLA 86Proceedings, September 1986, pp. 214-223.

A class defines a type of object that typically includes both instancevariables and methods for the class. An object class is used to create aparticular instance of an object. An instance of an object classincludes the variables and methods defined for the class. Multipleinstances of a the same class can created from an object class. Eachinstance that is created from the object class is said to be of the sametype or class.

A hierarchy of classes can be defined such that an object classdefinition has one or more subclasses. A subclass inherits its parent's(and grandparent's etc.) definition. Each subclass in the hierarchy mayadd to or modify the behavior specified by its parent class.

To illustrate, an employee object class can include “name” and “salary”instance variables and a “set_salary” method. Instances of the employeeobject class can be created, or instantiated for each employee in anorganization. Each object instance is said to be of type “employee.”Each employee object instance includes the “name” and “salary” instancevariables and the “set_salary” method. The values associated with the“name” and “salary” variables in each employee object instance containthe name and salary of an employee in the organization. A message can besent to an employee's employee object instance to invoke the“set_salary” method to modify the employee's salary (i.e., the valueassociated with the “salary” variable in the employee's employeeobject).

An object is a generic term that is used in the object-orientedprogramming environment to refer to a module that contains related codeand variables. A software program can be written using anobject-oriented programming language whereby the program's functionalityis implemented using objects.

Development of software applications may be performed in an independentpiecewise manner by establishing application programming interfaces(APIs) for components of the application. An API refers to the methodsof a particular component that are accessible by other components, andthe format by which those methods may be invoked. The particularimplementation of those methods is important only with respect to thedesign of the particular component. Each component is designedindividually to implement its respective API and any internal functions,and to interface with the APIs of the other components of theapplication. Typically, these components comprise one or more objectsforming the application.

Examples of object-oriented programming languages include C++ and Java.Unlike most programming languages, in which a program is compiled intomachine-dependent, executable program code, Java classes are compiledinto machine independent byte-code class files which are executed by amachine-dependent virtual machine. The virtual machine provides a levelof abstraction between the machine independence of the byte-code classesand the machine-dependent instruction set of the underlying computerhardware. A class loader is responsible for loading the byte-code classfiles as needed, and an interpreter or just-in-time compiler providesfor the transformation of byte-codes into machine code.

Embodiment of Computer Execution Environment (Hardware)

An embodiment of the invention can be implemented as computer softwarein the form of computer readable program code executed on a generalpurpose computer such as computer 100 illustrated in FIG. 1. A keyboard110 and mouse 111 are coupled to a bi-directional system bus 118. Thekeyboard and mouse are for introducing user input to the computer systemand communicating that user input to central processing unit (CPU) 113.Other suitable input devices may be used in addition to, or in place of,the mouse 111 and keyboard 110. I/O (input/output) unit 119 coupled tobi-directional system bus 118 represents such I/O elements as a printer,A/V (audio/video) I/O, etc.

Computer 100 includes a video memory 114, main memory 115 and massstorage 112, all coupled to bi-directional system bus 118 along withkeyboard 110, mouse 111 and CPU 113. The mass storage 112 may includeboth fixed and removable media, such as magnetic, optical or magneticoptical storage systems or any other available mass storage technology.Bus 118 may contain, for example, thirty-two address lines foraddressing video memory 114 or main memory 115. The system bus 118 alsoincludes, for example, a 32-bit data bus for transferring data betweenand among the components, such as CPU 113, main memory 115, video memory114 and mass storage 112. Alternatively, multiplex data/address linesmay be used instead of separate data and address lines.

In one embodiment of the invention, the CPU 113 is a microprocessormanufactured by Motorola®, such as the 680X0 processor or amicroprocessor manufactured by Intel®, such as the 80X86, or Pentium®processor, or a SPARC® microprocessor from Sun Microsystems®. However,any other suitable microprocessor or microcomputer may be utilized. Mainmemory 115 is comprised of dynamic random access memory (DRAM). Videomemory 114 is a dual-ported video random access memory. One port of thevideo memory 114 is coupled to video amplifier 116. The video amplifier116 is used to drive the cathode ray tube (CRT) raster monitor 117.Video amplifier 116 is well known in the art and may be implemented byany suitable apparatus. This circuitry converts pixel data stored invideo memory 114 to a raster signal suitable for use by monitor 117.Monitor 117 is a type of monitor suitable for displaying graphic images.

Computer 100 may also include a communication interface 120 coupled tobus 118. Communication interface 120 provides a two-way datacommunication coupling via a network link 121 to a local network 122.For example, if communication interface 120 is an integrated servicesdigital network (ISDN) card or a modem, communication interface 120provides a data communication connection to the corresponding type oftelephone line, which comprises part of network link 121. Ifcommunication interface 120 is a local area network (LAN) card,communication interface 120 provides a data communication connection vianetwork link 121 to a compatible LAN. Wireless links are also possible.In any such implementation, communication interface 120 sends andreceives electrical, electromagnetic or optical signals which carrydigital data streams representing various types of information.

Network link 121 typically provides data communication through one ormore networks to other data devices. For example, network link 121 mayprovide a connection through local network 122 to host computer 123 orto data equipment operated by an Internet Service Provider (ISP) 124.ISP 124 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 125. Local network 122 and Internet 125 both use electrical,electromagnetic or optical signals which carry digital data streams. Thesignals through the various networks and the signals on network link 121and through communication interface 120, which carry the digital data toand from computer 100, are exemplary forms of carrier waves transportingthe information.

Computer 100 can send messages and receive data, including program code,through the network(s), network link 121, and communication interface120. In the Internet example, server 126 might transmit a requested codefor an application program through Internet 125, ISP 124, local network122 and communication interface 120.

The received code may be executed by CPU 113 as it is received, and/orstored in mass storage 112, or other non-volatile storage for laterexecution. In this manner, computer 100 may obtain application code inthe form of a carrier wave.

The computer systems described above are for purposes of example only.An embodiment of the invention may be implemented in any type ofcomputer system or programming or processing environment.

PREFERRED EMBODIMENT

The present invention provides a system that permits the use of aselectable depacketizer. The preferred embodiment of the presentinvention contemplates the use of RTP and the use of an RTP sessionmanager to handle the receipt of data (in the preferred embodiment,video or audio data). The RTP session manager is described below.

RTP SESSION MANAGER

The RTP Session Manager (RTPSM) allows a local participant toparticipate (send or receive data) in a single RTP “session”. The RTPSMmaintains an updated state of the session as viewed from the localparticipant. In effect, an instance of an RTPSM is a localrepresentation of a distributed entity (an RTP session). It allows anapplication to render and create data streams on an RTP session. Oneembodiment of this invention takes advantage of the Java Media Framework(JMF) described in Appendix A herein.

A graphical representation of the RTP Session Manager is illustrated inFIG. 2. The java media package manager 201 handles the creation ofplayers and locates the appropriate players. Manager 201 is part of theJMF. The Java Media Framework (JMF) is a set of multimedia APIs andimplementations designed to playback multimedia in a variety ofprotocols and formats, such as a QuickTime Cinepak movie over the HTTP(Hypertext Transfer Protocol) protocol. The Java Media Frameworkspecifies the concept of a “player,” a unit to playback multimedia data.

Transport delivery 202 receives data streams from the network andprovides them, via RTPSocket 203, the to RTP Session Manager 204. TheSession Manager 204 inspects the RTP packet and determines what theencoding is. Depending on the type of encoding, the Session Manager 204identifies and invokes the appropriate depacketizer 206. The SessionManager 204 sends RTP packets to the depacketizer 206. The depacketizer206 assembles the packets into frames as appropriate for the codecenvironment of the packets and sends them via the Session Manager 204 tothe handler 205. Handler 205 decodes the frames and provides playback asappropriate.

The RTPSM 204 represents the session with two dynamic sets of objects —aset of “participants” and a set of “streams”. The stream is provided bytransport delivery 202. These objects are created by and controlled bythe RTPSM. A participant is a single machine, host or user participatingin the session, while a stream is a series of data packets arriving fromor sent by a single source. A participant may own more than one stream,each of which is identified by the SSRC used by the source of thestream.

At the top-most level the RTPSM manages a set of “participants”(RTPParticipant ), each represented by an instance of a classimplementing the RTPParticipant interface. RTPSM implementations createRTPParticipant whenever a previously unidentified RTCP (Real TimeControl Protocol) packet is received. (The RTPParticipant object isupdated each time a subsequent RTCP packet from this source arrives).

In addition to the set of RTPParticipant objects, an RTPSMimplementation also manages a set of RTPStream objects. Each such objectrepresents a stream of RTP data packets on the session; if the streamoriginates from the local participant (the client) it is an instance ofthe RTPSendStream subclass; otherwise the stream is coming off the netfrom a remote participant and is an instance of the RTPRecvStreamsubclass.

PLUGGABLE DEPACKETIZER ARCHITECTURE

The preferred embodiment of the present invention provides a scheme foridentifying an appropriate depacketizer module based on the codec typeof incoming data. The depacketizer module assembles data into frames andprovides it to a handler for decoding and playback. A flow diagram ofthis process is illustrated in FIG. 4.

At step 401 the RTP Session Manager receives a data stream. At Step 402RTPSM obtains the payload type of the data stream by parsing the RTPheader of the data.

At step 403 the appropriate depacketizer is called based on the resultsof the payload query in step 402. At step 404 the RTPSM calls thedepacketize( ) method of the depacketizer each time it has received andparsed an RTP packet on the stream of the depacketizer.

The depacketizer assembles protocol data units received in thedepacketize( ) method into application data units (frames) and notifiesits DePacketizedDataHandler when it has finished preparing a frame ofdata at step 405 (RTPSM sets the transferHandler of the depacketizeronce it has been instantiated using the depacketizer'ssetTransferHandler( ) method. The transferHandler of a depacketizer is aDePacketizedDataHandler and is the object to which depacketized datamust be handed over by the depacketizer). Notification is done bycalling the transferData( ) method of its DePacketizedDataHandler atstep 406. The DePacketizedDataHandler then takes care of streaming thedepacketized data to the handler of this stream at step 407.

Graphical Representation of the DePacketizer

The operation of the Depacketizer is represented graphically in FIG. 3.RTP streaming packets are delivered to the RTP Session Manager 204. TheRTP Session Manager examiners the first packet and examines the RTPheader. The packet includes information such as Extension Present, Type,byte array of extension data, marker, Payload Type, Sequence Number, RTPtimestamp, SSRC integer array of CSRC, and payload(offset, length). Theparsed RTP packet is then provided to the DepacketizedDataHandler 301.

The Depacketizer depacketizes the RTP packet into a DepacketizedUnit302. The DepacketizedUnit 302 includes a DepacketizedUnitHeader, atimestamp, a marker, payloadtype, payload header, and payload size.DepacketizedUnits are essentially data frames and are provided from thedepacketizer to the depacketizedatahandler which is part of the RTPSM.The RTPSM 204 will then provide this frame to the handler 205 fordecoding and playback.

Depacketizer Interface

In the Java language, an interface is a collection of constants andabstract methods. A class can implement an interface by adding theinterface to the class's “implements” clause. An abstract method can beoverridden (i.e. replaced). A variable can be declared as an interfacetype and all of the constants and methods declared in the interface canbe accessed from this variable.

The preferred embodiment of the present invention includes an interfacecalled “RTPDepacketizer”. This interface is implemented by all plug-indepacketizers in RTPSM in the preferred embodiment. The entry point fromthe RTPSM to the depacketizer is via the depacketize method. Applicationdata units or frames are transferred from the depacketizer to the RTPSMby calling the transferData( ) method of the DePacketizedDataHandler.The RTPSM is responsible for setting the DePacketizedDataHandler on adepacketizer. The Depacketizer interface implements the followingmethods:

depacketize

public abstract void depacketize(RTPPacket p)

Called by RTPSM when a RTP packet arrives from the network or on theRTPSocket's output data stream.

setTransferHandler

public abstract void setTransferHandler(DePacketizedDataHandler handler)

Used by RTPSM to set the transferHandler of this depacketizer. Thedepacketizer should call the transferData( ) method of itstransferHandler when it has finished preparing a application data unitor frame. Object passed to the DePacketizedDataHandler is aDepacketizedDataUnit

getMediaType

public abstract String getMediaType( )

Used by RTPSM to retrieve the media type of the stream. This can be oneof audio or video and is used to set content type of the RTPSM and thesource streams it prepares.

getCodecString

public abstract String getCodecString( )

Used by the RTPSM to set the codec string type on the data source streamit creates for the handler. This returns a string identifying the codecto be used. The Manager will locate a codec of typepackage-prefix.media.codec.mediatype.[codec-string].Codec.

public class DePacketizedUnitHeader

As illustrated in FIG. 3, a DePacketizedUnit includes aDePacketizedUnitHeader. A DePacketizedUnitHeader describes theDePacketizedUnit it belongs to. The header parameters are meant todescribe the depacketized unit as a whole. The header contains certainfields from the RTP header of a packet considered relevant to thedecoding and rendering process. In cases where the depacketizedUnitencompasses more than one RTP packet, the header needs to be filledcorrectly with data describing the unit as a whole. Programmers may havetheir own structure of the depacketized data unit or use the defaultclass provided by RTPSM.

The constructor for this class is DePacketizedUnitHeader(long, int, int,int, byte[ ], int).

public DePacketizedUnitHeader(long rtptimestamp,

int markerbit,

int payloadtype,

int payloadhdrsize,

byte payloadhdr[ ],

int payloadsize)

The parameters for this constructor are:

rtptimestamp—The RTP timestamp that came in protocol data units (RTPpackets)of this stream. These are passed to the handler as they could beused for transferring timing information and synchronization by thehandler

markerbit—The marker bit in the RTP Header of this application data unitor frame. i.e. set to 1 if the marker bit was set for this ADU.

payloadtype—payload type of the data in this depacketizedunit

payloadhdr—The payload specific header following the RTP header for thispayload type

payloadsize—Length of data in this DePacketizedUnit

The methods of this class are as follows:

getSize

public int getSize( )

getPayload

public int getPayload( )

getMarker

public int getMarker( )

getTimeStamp

public long getTimeStamp( )

getPayloadHdrSize

public int getPayloadHdrSize( )

getPayloadHdr

public byte[ ] getPayloadHdr( )

public interface RTPPayload

This is the interface implemented by all RTP datasources in order toquery the payload type of the data received on this datasource. If RTPdata has not yet been received on this datasource, it will return thefield UNKNOWN_PAYLOAD, a constant returned when no data has beenreceived on this datasource.

The methods for this interface are as follows:

setPayloadType

public abstract void setPayloadType(int type)

Used to set the payload of this datasource. If payload has previouslybeen set, it will be reset to this new payload type.

getPayloadType

public abstract int getPayloadType( )

Returns the payload type of this datasource

getCodecString

public abstract String getCodecString( )

Returns the Codec string for the codec to be used to decode data fromthis datasource

setCodecString

public abstract void setCodecString(String codec)

Used to set the codec string of the datasource/stream. If codec stringhas been previously set, it will be reset to this new codec string

Content Handlers

The invention provides a design that enables a programmer to plug-inhis/her own depacketizer. Content handlers for this depacketizer shouldbe available in order to playback this depacketized stream. In thepreferred embodiment, integration between the depacketizer and contenthandler is provided when depacketizers implement a pluggabledepacketizer interface and handlers are programmed to expect data in apre-determined format described below in connection with pluggabledepacketizers.

In the preferred embodiment, a default pre-determined format is providedin RTPSM, but this does not preclude the programmer from using his/herown format of depacketized data. Pluggable depacketizer naming andsearching conventions are designed according to JMF's player factoryarchitecture and use the same rules for integrating depacketizers intoRTPSM. For example, to integrate a new depacketizer into JMF,

1) The depacketizer implements the interface defined below.

2) Install the package containing the new depacketizer class.

3) Add the package prefix to the content prefix list controlled by thePackageManager.

4) The DePacketizerFactory queries the PackageManager for the list ofcontent package prefixes and search for<packageprefix>.media.rtp.depacketizer.avpx.DePacketizer class, where xis the RTP payload type for the installed depacketizer.

RTP Content Handlers are JMF players and should implement the methodsand semantics of a Java Media Player. Integrating new handlers orplayers is as explained in the JMF specification attached as anAppendix. The content type of RTP datasources created by the sessionmanager is one of “rtp/audio” or “rtp/video”. Manager will consequentlysearch for a handler of the type <package-prefix>.media.content.rtp.audio.Handler or <packageprefix>.media.content.rtp.video.Handler.

Note: JMF will not change handlers once a handler has been chosen andcreated by Manager. It is therefore important to note that the loadedHandler should be capable of supporting expected audio or video RTPpayload types in order to successfully playback data streams.

Manager creates the datasource and sets it on the handler. Thisdatasource is a PushDataSource and streams a PushSourceStream asexplained in the JMF specification in package javax.media.protocol.Handlers can read data from this stream as explained in thespecification. When the Manager creates a datasource and locates ahandler for it, it calls setsource( ) on the handler, passing it thedatasource. At this time, the handler returns anIncompatibleSourceException if it does not support the datasource. AllRTP datasources implement the javax.media.rtp.RTPPayload interface. ThegetPayloadType( ) method can be used by the handler to query the payloadtype of the datasource. If the handler does not support playback of thepayload type, it may return an IncompatibleSourceException. This causesManager to continue searching for a handler that does support thisdatasource. In this manner, implementations can default to usinghandlers in the system that do support a certain payload not supportedby this handler. Note: The RTP datasource can return a payload type onlyafter data has actually been received on it. This is not a guaranteedprocess to happen before the getPayload( ) call is issued. In the eventthat data is not received on the datasource, UNKNOWN_PAYLAOD is returnedby the datasource. The handler at this time can use its discretion andmake a decision to support any payloads expected on this stream or tothrow an IncompatibleSourceException.

The RTP Session Manager will stream data to the content handler as aPushSourceStream. The byte stream read by the handler is aDePacketizedObject converted to a stream of bytes. The structure of theobject need not be known to the RTPSM. It uses the toByteStream( )method of the interface to stream bytes from the DePacketizedObject tothe sourcestream of the handler. RTPSM provides a default implementationof the DePacketizedObject interface. i.e. DePacketizedUnit.java.Programmers can write depacketizers which create a DePacketizedUnitexplained injavax.media.rtp.RTPSessionManager.dePacketizer.DePacketizedUnit.java.The toByteStream( ) method has been implemented in DePacketizedUnit.Thus the user need not do anything more than create a DePacketizedUnit.

Thus, a method and apparatus for providing a selectable depacketizer hasbeen described in conjunction with one or more specific embodiments. Theinvention is defined by the claims and their full scope of equivalents.

What is claimed is:
 1. In a computer system having a plurality ofdepacketizers, a method configured to select a depacketizer for adatastream, said method comprising: installing a package containing anew depacketizer class, said package having prefixes; adding saidpackage prefixes to a list controlled by a package manager; receiving adatastream; selecting one of said plurality of depacketizers based on atype of data in said datastream; searching said list for a prefix basedon the type of data in said datastream to find a handler configured tointerface with said selected depacketizer; providing packets of saiddatastream to said selected depacketizer; assembling packets intoframes; providing said frames to said handler; decoding said frames intomedia data.